SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Flow-based programming</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Flow-based programming</span></span>

</h1>

</header>

<p>In <a href="Computer_programming" title="Computer programming">computer programming</a>, <b>flow-based programming</b> (<b>FBP</b>) is a <a href="Programming_paradigm" title="Programming paradigm">programming paradigm</a> that defines <a href="Application_software" title="Application software">applications</a> as networks of <a href="Black_box" title="Black box">black box</a> <a href="Process_(computer_science)" class="mw-redirect" title="Process (computer science)">processes</a>, which exchange data across predefined connections by <a href="Message_passing" title="Message passing">message passing</a>, where the connections are specified <i>externally</i> to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally <a href="Software_componentry" class="mw-redirect" title="Software componentry">component-oriented</a>.

</p><p>FBP is a particular form of <a href="Dataflow_programming" title="Dataflow programming">dataflow programming</a> based on bounded buffers, information packets with defined lifetimes, named ports, and separate definition of connections.

</p>

<div class="mw-heading mw-heading2"><h2 id="Introduction">Introduction</h2></div>

<p>Flow-based programming defines applications using the metaphor of a "data factory". It views an application not as a single, sequential process, which starts at a point in time, and then does one thing at a time until it is finished, but as a network of asynchronous processes communicating by means of <a href="Stream_(computing)" title="Stream (computing)">streams</a> of structured data chunks, called "information packets" (IPs). In this view, the focus is on the application data and the transformations applied to it to produce the desired outputs. The network is defined externally to the processes, as a list of connections which is interpreted by a piece of software, usually called the "scheduler".

</p><p>The processes communicate by means of fixed-capacity connections. A connection is attached to a process by means of a <a href="Computer_port_(software)" class="mw-redirect" title="Computer port (software)">port</a>, which has a name agreed upon between the process code and the network definition. More than one process can execute the same piece of code. At any point in time, a given IP can only be "owned" by a single process, or be in transit between two processes. <a href="Computer_port_(software)" class="mw-redirect" title="Computer port (software)">Ports</a> may either be simple, or array-type, as used e.g. for the input port of the Collate component described below. It is the combination of ports with asynchronous processes that allows many long-running primitive functions of data processing, such as Sort, Merge, Summarize, etc., to be supported in the form of software <a href="Black_box" title="Black box">black boxes</a>.

</p><p>Because FBP processes can continue executing as long they have data to work on and somewhere to put their output, FBP applications generally run in less elapsed time than conventional programs, and make optimal use of all the processors on a machine, with no special programming required to achieve this.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p><p>The network definition is usually diagrammatic, and is converted into a connection list in some lower-level language or notation. FBP is often a <a href="Visual_programming_language" title="Visual programming language">visual programming language</a> at this level. More complex network definitions have a hierarchical structure, being built up from subnets with "sticky" connections. Many other flow-based languages/runtimes are built around more traditional programming languages, the most notable example is <a href="RaftLib" title="RaftLib">RaftLib</a> which uses C++ iostream-like operators to specify the flow graph.

</p><p>FBP has much in common with the <a href="Linda_(coordination_language)" title="Linda (coordination language)">Linda</a><sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> language in that it is, in <a href="David_Gelernter" title="David Gelernter">Gelernter</a> and Carriero's terminology, a "coordination language":<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> it is essentially language-independent. Indeed, given a scheduler written in a sufficiently low-level language, components written in different languages can be linked together in a single network. FBP thus lends itself to the concept of <a href="Domain-specific_language" title="Domain-specific language">domain-specific languages</a> or "mini-languages".

</p><p>FBP exhibits "data coupling", described in the article on <a href="Coupling_(computer_science)" class="mw-redirect" title="Coupling (computer science)">coupling</a> as the loosest type of coupling between components. The concept of <a href="Loose_coupling" title="Loose coupling">loose coupling</a> is in turn related to that of <a href="Service-oriented_architecture" title="Service-oriented architecture">service-oriented architectures</a>, and FBP fits a number of the criteria for such an architecture, albeit at a more fine-grained level than most examples of this architecture.

</p><p>FBP promotes high-level, functional style of specifications that simplify reasoning about system behavior. An example of this is the <a href="Distributed_data_flow" title="Distributed data flow">distributed data flow</a> model for constructively specifying and analyzing the semantics of distributed multi-party protocols.

</p>

<div class="mw-heading mw-heading2"><h2 id="History">History</h2></div>

<p>Flow-based programming was invented by <a href="J._Paul_Morrison" title="J. Paul Morrison">J. Paul Morrison</a> in the early 1970s, and initially implemented in software for a Canadian bank.<sup id="cite_ref-Stein2013_4-0" class="reference"><a href="#cite_note-Stein2013-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> FBP at its inception was strongly influenced by some IBM simulation languages of the period, in particular <a href="GPSS" title="GPSS">GPSS</a>, but its roots go all the way back to <a href="Melvin_Conway" title="Melvin Conway">Conway</a>'s seminal paper on what he called <a href="Coroutines" class="mw-redirect" title="Coroutines">coroutines</a>.<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>

</p><p>FBP has undergone a number of name changes over the years: the original implementation was called AMPS (Advanced Modular Processing System). One large application in Canada went live in 1975, and, as of 2013, has been in continuous production use, running daily, for almost 40 years. Because IBM considered the ideas behind FBP "too much like a law of nature" to be patentable they instead put the basic concepts of FBP into the public domain, by means of a <a href="Technical_Disclosure_Bulletins" class="mw-redirect" title="Technical Disclosure Bulletins">Technical Disclosure Bulletin</a>, "Data Responsive Modular, Interleaved Task Programming System",<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> in 1971.<sup id="cite_ref-Stein2013_4-1" class="reference"><a href="#cite_note-Stein2013-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> An article describing its concepts and experience using it was published in 1978 in the <a href="IBM_Research" title="IBM Research">IBM Research</a> IBM Systems Journal under the name DSLM.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup> A second implementation was done as a joint project of IBM Canada and IBM Japan, under the name "Data Flow Development Manager" (DFDM), and was briefly marketed in Japan in the late '80s under the name "Data Flow Programming Manager".

</p><p>Generally the concepts were referred to within IBM as "Data Flow", but this term was felt to be too general, and eventually the name "Flow-Based Programming" was adopted.

</p><p>From the early '80s to 1993 J. Paul Morrison and IBM architect <a href="Wayne_Stevens_(software_engineer)" title="Wayne Stevens (software engineer)">Wayne Stevens</a> refined and promoted the concepts behind FBP. Stevens wrote several articles describing and supporting the FBP concept, and included material about it in several of his books.<sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-W.P._Stevens,_1990_10-0" class="reference"><a href="#cite_note-W.P._Stevens,_1990-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>. In 1994 Morrison published a book describing FBP, and providing empirical evidence that FBP led to reduced development times.<sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Concepts">Concepts</h2></div>

<p>The following diagram shows the major entities of an FBP diagram (apart from the Information Packets). Such a diagram can be converted directly into a list of connections, which can then be executed by an appropriate engine (software or hardware).

</p>

<p>A, B and C are processes executing code components. O1, O2, and the two INs are ports connecting the connections M and N to their respective processes. It is permitted for processes B and C to be executing the same code, so each process must have its own set of working storage, control blocks, etc. Whether or not they do share code, B and C are free to use the same port names, as port names only have meaning within the components referencing them (and at the network level, of course).

</p><p>M and N are what are often referred to as "<a href="Circular_buffer" title="Circular buffer">bounded buffers</a>", and have a fixed capacity in terms of the number of IPs that they can hold at any point in time.

</p><p>The concept of <i>ports</i> is what allows the same component to be used at more than one place in the network. In combination with a parametrization ability, called Initial Information Packets (IIPs), ports provide FBP with a component reuse ability, making FBP a <a href="Component-based_software_engineering" title="Component-based software engineering">component-based</a> architecture. FBP thus exhibits what Raoul de Campo and <a href="Nate_Edwards" title="Nate Edwards">Nate Edwards</a> of <a href="IBM_Research" title="IBM Research">IBM Research</a> have termed <a href="Configurable_modularity" title="Configurable modularity">configurable modularity</a>.

</p><p>Information Packets or IPs are allocated in what might be called "IP space" (just as Linda's tuples are allocated in "tuple space"), and have a well-defined lifetime until they are disposed of and their space is reclaimed - in FBP this must be an explicit action on the part of an owning process. IPs traveling across a given connection (actually it is their "handles" that travel) constitute a "stream", which is generated and consumed asynchronously - this concept thus has similarities to the <a href="Lazy_evaluation" title="Lazy evaluation">lazy cons</a> concept described in the 1976 article by Friedman and Wise.<sup id="cite_ref-12" class="reference"><a href="#cite_note-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>

</p><p>IPs are usually structured chunks of data - some IPs, however, may not contain any real data, but are used simply as signals. An example of this is "bracket IPs", which can be used to group data IPs into sequential patterns within a stream, called "substreams". Substreams may in turn be nested. IPs may also be chained together to form "IP trees", which travel through the network as single objects.

</p><p>The system of connections and processes described above can be "ramified" to any size. During the development of an application, monitoring processes may be added between pairs of processes, processes may be "exploded" to subnets, or simulations of processes may be replaced by the real process logic. FBP therefore lends itself to <a href="Software_prototyping" title="Software prototyping">rapid prototyping</a>.

</p><p>This is really an <a href="Assembly_line" title="Assembly line">assembly line</a> image of data processing: the IPs travelling through a network of processes may be thought of as widgets travelling from station to station in an assembly line. "Machines" may easily be reconnected, taken off line for repair, replaced, and so on. Oddly enough, this image is very similar to that of <a href="Unit_record_equipment" title="Unit record equipment">unit record equipment</a> that was used to process data before the days of computers, except that decks of cards had to be hand-carried from one machine to another.

</p><p>Implementations of FBP may be non-preemptive or preemptive - the earlier implementations tended to be non-preemptive (mainframe and C language), whereas the latest Java implementation (see below) uses Java Thread class and is preemptive.

</p>

<div class="mw-heading mw-heading2"><h2 id="Examples">Examples</h2></div>

<div class="mw-heading mw-heading3"><h3 id="The_telegram_problem">The telegram problem</h3></div>

<p>FBP components often form complementary pairs. This example uses two such pairs. The problem described seems very simple as described in words, but in fact is surprisingly difficult to accomplish using conventional procedural logic. The task, called the "telegram problem", originally described by <a href="Peter_Naur" title="Peter Naur">Peter Naur</a>, is to write a program which accepts lines of text and generates output lines containing as many words as possible, where the number of characters in each line does not exceed a certain length. The words may not be split and we assume no word is longer than the size of the output lines. This is analogous to the word-wrapping problem in text editors.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup>

</p><p>In conventional logic, the programmer rapidly discovers that neither the input nor the output structures can be used to drive the call hierarchy of <a href="Control_flow" title="Control flow">control flow</a>. In FBP, on the other hand, the problem description itself suggests a solution:

</p>

<ul><li>"Words" are mentioned explicitly in the description of the problem, so it is reasonable for the designer to treat words as information packets (IPs)</li>

<li>In FBP there is no single call hierarchy, so the programmer is not tempted to force a sub-pattern of the solution to be the top level.</li></ul>

<p>Here is the most natural solution in FBP (there is no single "correct" solution in FBP, but this seems like a natural fit):

</p>

<p>where DC and RC stand for "DeCompose" and "ReCompose", respectively.

</p><p>As mentioned above, Initial Information Packets (IIPs) can be used to specify parametric information such as the desired output record length (required by the rightmost two components), or file names. IIPs are data chunks associated with a port in the network definition which become "normal" IPs when a "receive" is issued for the relevant port.

</p>

<div class="mw-heading mw-heading3"><h3 id="Batch_update">Batch update</h3></div>

<p>This type of program involves passing a file of "details" (changes, adds and deletes) against a "master file", and producing (at least) an updated master file, and one or more reports. Update programs are generally quite hard to code using synchronous, procedural code, as two (sometimes more) input streams have to be kept synchronized, even though there may be masters without corresponding details, or vice versa.

</p>

<p>In FBP, a reusable component (Collate), based on the <a href="Unit_record_equipment" title="Unit record equipment">unit record</a> idea of a Collator, makes writing this type of application much easier as Collate merges the two streams and inserts bracket IPs to indicate grouping levels, significantly simplifying the downstream logic. Suppose that one stream ("masters" in this case) consists of IPs with key values of 1, 2 and 3, and the second stream IPs ("details") have key values of 11, 12, 21, 31, 32, 33 and 41, where the first digit corresponds to the master key values. Using bracket characters to represent "bracket" IPs, the collated output stream will be as follows:

</p>

<pre>( m1 d11 d12 ) ( m2 d21 ) ( m3 d31 d32 d33 ) (d41)

</pre>

<p>As there was no master with a value of 4, the last group consists of a single detail (plus brackets).

</p><p>The structure of the above stream can be described succinctly using a <a href="Backus%E2%80%93Naur_form" title="Backus–Naur form">BNF</a>-like notation such as

</p>

<pre>{ ( [m] d* ) }*

</pre>

<p>Collate is a reusable <a href="Black_box_(systems)" class="mw-redirect" title="Black box (systems)">black box</a> which only needs to know where the control fields are in its incoming IPs (even this is not strictly necessary as transformer processes can be inserted upstream to place the control fields in standard locations), and can in fact be generalized to any number of input streams, and any depth of bracket nesting. Collate uses an array-type port for input, allowing a variable number of input streams.

</p>

<div class="mw-heading mw-heading3"><h3 id="Multiplexing_processes">Multiplexing processes</h3></div>

<p>Flow-based programming supports process multiplexing in a very natural way. Since components are read-only, any number of instances of a given component ("processes") can run asynchronously with each other.

</p>

<p>When computers usually had a single processor, this was useful when a lot of I/O was going on; now that machines usually have multiple processors, this is starting to become useful when processes are CPU-intensive as well. The diagram in this section shows a single "Load Balancer" process distributing data between three processes, labeled S1, S2 and S3, respectively, which are instances of a single component, which in turn feed into a single process on a "first-come, first served" basis.

</p>

<div class="mw-heading mw-heading3"><h3 id="Simple_interactive_network">Simple interactive network</h3></div>

<p>In this general schematic, requests (transactions) coming from users enter the diagram at the upper left, and responses are returned at the lower left. The "back ends" (on the right side) communicate with systems at other sites, e.g. using <a href="Common_Object_Request_Broker_Architecture" title="Common Object Request Broker Architecture">CORBA</a>, <a href="MQSeries" class="mw-redirect" title="MQSeries">MQSeries</a>, etc. The cross-connections represent requests that do not need to go to the back ends, or requests that have to cycle through the network more than once before being returned to the user.

</p><p>As different requests may use different back-ends, and may require differing amounts of time for the back-ends (if used) to process them, provision must be made to relate returned data to the appropriate requesting transactions, e.g. <a href="Hash_table" title="Hash table">hash tables</a> or caches.

</p><p>The above diagram is schematic in the sense that the final application may contain many more processes: processes may be inserted between other processes to manage caches, display connection traffic, monitor throughput, etc. Also the blocks in the diagram may represent "subnets" - small networks with one or more open connections.

</p>

<div class="mw-heading mw-heading2"><h2 id="Comparison_with_other_paradigms_and_methodologies">Comparison with other paradigms and methodologies</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Jackson_Structured_Programming_(JSP)_and_Jackson_System_Development_(JSD)">Jackson Structured Programming (JSP) and Jackson System Development (JSD)</h3></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">Main articles: <a href="Jackson_Structured_Programming" class="mw-redirect" title="Jackson Structured Programming">Jackson Structured Programming</a> and <a href="Jackson_System_Development" class="mw-redirect" title="Jackson System Development">Jackson System Development</a></div>

<p>This methodology assumes that a program must be structured as a single procedural hierarchy of subroutines. Its starting point is to describe the application as a set of "main lines", based on the input and output data structures. One of these "main lines" is then chosen to drive the whole program, and the others are required to be "inverted" to turn them into subroutines (hence the name "Jackson inversion"). This sometimes results in what is called a "clash", requiring the program to be split into multiple programs or coroutines. When using FBP, this inversion process is not required, as every FBP component can be considered a separate "main line".

</p><p>FBP and JSP share the concept of treating a program (or some components) as a <a href="Parser" class="mw-redirect" title="Parser">parser</a> of an input stream.

</p><p>In Jackson's later work, <a href="Jackson_System_Development" class="mw-redirect" title="Jackson System Development">Jackson System Development</a> (JSD), the ideas were developed further.<sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-jsd_15-0" class="reference"><a href="#cite_note-jsd-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup>

</p><p>In JSD the design is maintained as a network design until the final implementation stage. The model is then transformed into a set of sequential processes to the number of available processors. Jackson discusses the possibility of directly executing the network model that exists prior to this step, in section 1.3 of his book (italics added):

</p>

<dl><dd>The specification produced at the end of the System Timing step is, in principle, capable of direct execution. The necessary environment would contain a processor for each process, a device equivalent to an unbounded buffer for each data stream, and some input and output devices where the system is connected to the real world. <i>Such an environment could, of course, be provided by suitable software running on a sufficiently powerful machine. Sometimes, such direct execution of the specification will be possible, and may even be a reasonable choice.</i><sup id="cite_ref-jsd_15-1" class="reference"><a href="#cite_note-jsd-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup></dd></dl>

<p>FBP was recognized by M A Jackson as an approach that follows his method of "Program decomposition into sequential processes communicating by a coroutine-like mechanism"<sup id="cite_ref-jsp_in_perspective_16-0" class="reference"><a href="#cite_note-jsp_in_perspective-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Applicative_programming">Applicative programming</h3></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Applicative_programming_language" title="Applicative programming language">Applicative programming language</a></div>

<p>W.B. Ackerman defines an applicative language as one which does all of its processing by means of operators applied to values.<sup id="cite_ref-17" class="reference"><a href="#cite_note-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup> The earliest known applicative language was LISP.

</p><p>An FBP component can be regarded as a function transforming its input stream(s) into its output stream(s). These functions are then combined to make more complex transformations, as shown here:

</p>

<p>If we label streams, as shown, with lower case letters, then the above diagram can be represented succinctly as follows:

</p>

<pre>c = G(F(a),F(b));

</pre>

<p>Just as in functional notation F can be used twice because it only works with values, and therefore has no side effects, in FBP two instances of a given component may be running concurrently with each other, and therefore FBP components must not have side-effects either. Functional notation could clearly be used to represent at least a part of an FBP network.

</p><p>The question then arises whether FBP components can themselves be expressed using functional notation. W.H. Burge showed how stream expressions can be developed using a recursive, applicative style of programming, but this work was in terms of (streams of) atomic values.<sup id="cite_ref-18" class="reference"><a href="#cite_note-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup> In FBP, it is necessary to be able to describe and process structured data chunks (FBP IPs).

</p><p>Furthermore, most applicative systems assume that all the data is available in memory at the same time, whereas FBP applications need to be able to process long-running streams of data while still using finite resources. Friedman and Wise suggested a way to do this by adding the concept of <a href="Lazy_evaluation" title="Lazy evaluation">"lazy cons"</a> to Burge's work. This removed the requirement that both of the arguments of "cons" be available at the same instant of time. "Lazy cons" does not actually build a stream until both of its arguments are realized - before that it simply records a "promise" to do this. This allows a stream to be dynamically realized from the front, but with an unrealized back end. The end of the stream stays unrealized until the very end of the process, while the beginning is an ever-lengthening sequence of items.

</p>

<div class="mw-heading mw-heading3"><h3 id="Linda">Linda</h3></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Linda_(coordination_language)" title="Linda (coordination language)">Linda</a></div>

<p>Many of the concepts in FBP seem to have been discovered independently in different systems over the years. Linda, mentioned above, is one such. The difference between the two techniques is illustrated by the Linda "school of piranhas" <a href="Load_balancing_(computing)" title="Load balancing (computing)">load balancing</a> technique - in FBP, this requires an extra "load balancer" component which routes requests to the component in a list which has the smallest number of IPs waiting to be processed. Clearly FBP and Linda are closely related, and one could easily be used to simulate the other.

</p>

<div class="mw-heading mw-heading3"><h3 id="Object-oriented_programming">Object-oriented programming</h3></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Object-oriented_programming" title="Object-oriented programming">Object-oriented programming</a></div>

<p>An object in <a href="Object-oriented_programming" title="Object-oriented programming">OOP</a> can be described as a semi-autonomous unit comprising both information and behaviour. Objects communicate by means of "method calls", which are essentially subroutine calls, done indirectly via the class to which the receiving object belongs. The object's internal data can only be accessed by means of method calls, so this is a form of <a href="Information_hiding" title="Information hiding">information hiding</a> or "encapsulation". Encapsulation, however, predates OOP - <a href="David_Parnas" title="David Parnas">David Parnas</a> wrote one of the seminal articles on it in the early 70s<sup id="cite_ref-19" class="reference"><a href="#cite_note-19"><span class="cite-bracket">[</span>19<span class="cite-bracket">]</span></a></sup> - and is a basic concept in computing. Encapsulation is the very essence of an FBP component, which may be thought of as a <a href="Black_box" title="Black box">black box</a>, performing some conversion of its input data into its output data. In FBP, part of the specification of a component is the data formats and stream structures that it can accept, and those it will generate. This constitutes a form of <a href="Design_by_contract" title="Design by contract">design by contract</a>. In addition, the data in an IP can only be accessed directly by the currently owning process. Encapsulation can also be implemented at the network level, by having outer processes protect inner ones.

</p><p>A paper by C. Ellis and S. Gibbs distinguishes between <a href="Active_object" title="Active object">active objects</a> and passive objects.<sup id="cite_ref-20" class="reference"><a href="#cite_note-20"><span class="cite-bracket">[</span>20<span class="cite-bracket">]</span></a></sup> Passive objects comprise information and behaviour, as stated above, but they cannot determine the <i>timing</i> of this behaviour. Active objects on the other hand can do this. In their article Ellis and Gibbs state that active objects have much more potential for the development of maintainable systems than do passive objects. An FBP application can be viewed as a combination of these two types of object, where FBP processes would correspond to active objects, while IPs would correspond to passive objects.

</p>

<div class="mw-heading mw-heading3"><h3 id="Actor_model">Actor model</h3></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Actor_model" title="Actor model">Actor model</a></div>

<p>FBP considers <a href="Carl_Hewitt" title="Carl Hewitt">Carl Hewitt</a>'s <a href="Actor_model" title="Actor model">actor</a> as an asynchronous processes with 2 ports: one for input messages and one for control signals. A control signal is emitted by the actor itself after each round of execution. The purpose of this signal is to avoid parallel execution of the actor's body and so to allow to access the fields of the actor object without synchronization.

</p>

<ul><li><a href="Active_objects" class="mw-redirect" title="Active objects">Active objects</a></li>

<li><a href="Actor_model" title="Actor model">Actor model</a></li>

<li><a href="Apache_NiFi" title="Apache NiFi">Apache NiFi</a></li>

<li><a href="BMDFM" class="mw-redirect" title="BMDFM">BMDFM</a></li>

<li><a href="Communicating_Sequential_Processes" class="mw-redirect" title="Communicating Sequential Processes">Communicating Sequential Processes (CSP)</a></li>

<li><a href="Concurrent_computing" title="Concurrent computing">Concurrent computing</a></li>

<li><a href="Dataflow" title="Dataflow">Dataflow</a></li>

<li><a href="Data_flow_diagram" class="mw-redirect" title="Data flow diagram">Data flow diagram</a></li>

<li><a href="Dataflow_programming" title="Dataflow programming">Dataflow programming</a></li>

<li><a href="IEC_61131" title="IEC 61131">FBD - Function Block Diagrams (a programming language in the IEC 61131 standard)</a></li>

<li><a href="Functional_reactive_programming" title="Functional reactive programming">Functional reactive programming</a></li>

<li><a href="Linda_(coordination_language)" title="Linda (coordination language)">Linda (coordination language)</a></li>

<li><a href="Low-code_development_platforms" class="mw-redirect" title="Low-code development platforms">Low-code development platforms</a></li>

<li><a href="MapReduce" title="MapReduce">MapReduce</a></li>

<li><a href="Pipeline_programming" class="mw-redirect" title="Pipeline programming">Pipeline programming</a></li>

<li><a href="Wayne_Stevens_(software_engineer)" title="Wayne Stevens (software engineer)">Wayne Stevens</a></li>

<li><a href="XProc" title="XProc">XProc</a></li>

<li><a href="Yahoo_Pipes" title="Yahoo Pipes">Yahoo Pipes</a></li>

<li>Smowcode</li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist reflist-columns references-column-width reflist-columns-2">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://jpaulm.github.io/fbp/index.html">"Flow-based Programming"</a>.</cite></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text"><cite id="CITEREFCarrieroGelernter1989" class="citation journal cs1">Carriero, Nicholas; Gelernter, David (1989). <a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F63334.63337">"Linda in context"</a>. <i>Communications of the ACM</i>. <b>32</b> (4): <span class="nowrap">444–</span>458. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F63334.63337">10.1145/63334.63337</a></span>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:5900105">5900105</a>.</cite></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text"><cite id="CITEREFGelernterCarriero1992" class="citation journal cs1">Gelernter, David; Carriero, Nicholas (1992). "Coordination languages and their significance". <i>Communications of the ACM</i>. <b>35</b> (2): <span class="nowrap">97–</span>107. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F129630.129635">10.1145/129630.129635</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:7748555">7748555</a>.</cite></span>

</li>

<li id="cite_note-Stein2013-4"><span class="mw-cite-backlink">^ <a href="#cite_ref-Stein2013_4-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Stein2013_4-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFGabe_Stein2013" class="citation web cs1">Gabe Stein (August 2013). <a rel="nofollow" class="external text" href="http://www.fastcompany.com/3016289/how-an-arcane-coding-method-from-1970s-banking-software-could-save-the-sanity-of-web-develop">"How an Arcane Coding Method From 1970s Banking Software Could Save the Sanity of Web Developers Everywhere"</a>. <i>Fast Company</i><span class="reference-accessdate">. Retrieved <span class="nowrap">24 January</span> 2016</span>.</cite></span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-5">^</a></b></span> <span class="reference-text"><cite id="CITEREFConway1963" class="citation journal cs1">Conway, Melvin E. (1963). <a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F366663.366704">"Design of a separable transition-diagram compiler"</a>. <i>Communications of the ACM</i>. <b>6</b> (7): <span class="nowrap">396–</span>408. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F366663.366704">10.1145/366663.366704</a></span>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:10559786">10559786</a>.</cite></span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-6">^</a></b></span> <span class="reference-text">J. Paul Morrison, <i>Data Responsive Modular, Interleaved Task Programming System,</i> IBM Technical Disclosure Bulletin, Vol. 13, No. 8, 2425-2426, January 1971</span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-7">^</a></b></span> <span class="reference-text"><cite id="CITEREFMorrison1978" class="citation journal cs1">Morrison, J. P. (1978). "Data Stream Linkage Mechanism". <i>IBM Systems Journal</i>. <b>17</b> (4): <span class="nowrap">383–</span>408. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1147%2Fsj.174.0383">10.1147/sj.174.0383</a>.</cite></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><b><a href="#cite_ref-8">^</a></b></span> <span class="reference-text"><cite id="CITEREFStevens1982" class="citation journal cs1">Stevens, W. P. (1982). "How data flow can improve application development productivity". <i>IBM Systems Journal</i>. <b>21</b> (2): <span class="nowrap">162–</span>178. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1147%2Fsj.212.0162">10.1147/sj.212.0162</a>.</cite></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-9">^</a></b></span> <span class="reference-text">W.P. Stevens, <i>Using Data Flow for Application Development</i>, Byte, June 1985</span>

</li>

<li id="cite_note-W.P._Stevens,_1990-10"><span class="mw-cite-backlink"><b><a href="#cite_ref-W.P._Stevens,_1990_10-0">^</a></b></span> <span class="reference-text">W.P. Stevens, <i>Software Design - Concepts and Methods</i>, Practical Software Engineering Series, Ed. Allen Macro, Prentice Hall, 1990, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-13-820242-7</bdi></span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><b><a href="#cite_ref-11">^</a></b></span> <span class="reference-text"><cite id="CITEREFJohnstonHannaMillar2004" class="citation journal cs1">Johnston, Wesley M.; Hanna, J. R. Paul; Millar, Richard J. (2004). "Advances in dataflow programming languages". <i>ACM Computing Surveys</i>. <b>36</b> (1): <span class="nowrap">1–</span>34. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.99.7265">10.1.1.99.7265</a></span>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F1013208.1013209">10.1145/1013208.1013209</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:5257722">5257722</a>.</cite></span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><b><a href="#cite_ref-12">^</a></b></span> <span class="reference-text">D.P. Friedman and D.S. Wise, <i>CONS should not evaluate its arguments,</i> Automata, Languages and Programming, Edinburgh University Press, Edinburgh, 1976</span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><b><a href="#cite_ref-13">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20140906085522/http://cecs.wright.edu/people/faculty/pmateti/Courses/7140/Lectures/TelegramProblem/telegram-problem.html">"Peter Naur's "Telegram Problem""</a>. Archived from <a rel="nofollow" class="external text" href="http://cecs.wright.edu/people/faculty/pmateti/Courses/7140/Lectures/TelegramProblem/telegram-problem.html">the original</a> on 2014-09-06<span class="reference-accessdate">. Retrieved <span class="nowrap">2014-09-06</span></span>.</cite></span>

</li>

<li id="cite_note-14"><span class="mw-cite-backlink"><b><a href="#cite_ref-14">^</a></b></span> <span class="reference-text">"<a rel="nofollow" class="external text" href="http://mcs.open.ac.uk/mj665/cernpgmg.pdf">Programming</a>" by M. A. Jackson, published in <i>Proceedings of Workshop on Software in High-Energy Physics, pages 1-12</i>, CERN, Geneva, 4–6 October 1982</span>

</li>

<li id="cite_note-jsd-15"><span class="mw-cite-backlink">^ <a href="#cite_ref-jsd_15-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-jsd_15-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">"<a rel="nofollow" class="external text" href="http://www.ferg.org/papers/jackson--a_system_development_method.pdf">A System development method</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20120206005615/http://www.ferg.org/papers/jackson--a_system_development_method.pdf">Archived</a> 2012-02-06 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>" by M. A. Jackson, published in <i>Tools and notions for program construction: An advanced course</i>,

Cambridge University Press, 1982</span>

</li>

<li id="cite_note-jsp_in_perspective-16"><span class="mw-cite-backlink"><b><a href="#cite_ref-jsp_in_perspective_16-0">^</a></b></span> <span class="reference-text">"<a rel="nofollow" class="external text" href="http://mcs.open.ac.uk/mj665/JSPPers1.pdf">JSP In Perspective</a>" Michael Jackson; JSP in Perspective; in Software Pioneers: Contributions to Software Engineering; Manfred Broy, Ernst Denert eds; Springer, 2002</span>

</li>

<li id="cite_note-17"><span class="mw-cite-backlink"><b><a href="#cite_ref-17">^</a></b></span> <span class="reference-text">W.B. Ackerman, <i>Data Flow Languages</i>, Proceedings National Computer Conference, pp. 1087-1095, 1979</span>

</li>

<li id="cite_note-18"><span class="mw-cite-backlink"><b><a href="#cite_ref-18">^</a></b></span> <span class="reference-text">W.H. Burge, <i>Recursive Programming Techniques</i>, Addison-Wesley, Reading, MA, 1975</span>

</li>

<li id="cite_note-19"><span class="mw-cite-backlink"><b><a href="#cite_ref-19">^</a></b></span> <span class="reference-text"><cite id="CITEREFParnas1972" class="citation journal cs1">Parnas, D. L. (1972). <a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F361598.361623">"On the criteria to be used in decomposing systems into modules"</a>. <i>Communications of the ACM</i>. <b>15</b> (12): <span class="nowrap">1053–</span>1058. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F361598.361623">10.1145/361598.361623</a></span>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:53856438">53856438</a>.</cite></span>

</li>

<li id="cite_note-20"><span class="mw-cite-backlink"><b><a href="#cite_ref-20">^</a></b></span> <span class="reference-text">C. Ellis and S. Gibbs, <i>Active Objects: Realities and Possibilities</i>, in <i>Object-Oriented Concepts, Databases, and Applications</i>, eds. W. Kim and F.H. Lochovsky, ACM Press, Addison-Wesley, 1989</span>

</li>

</ol></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><cite id="CITEREFRazdow1997" class="citation journal cs1">Razdow, Allen (December 1997). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20050315045230/http://www.dmreview.com/article_sub.cfm?articleId=689">"Building Enterprise Data Refineries"</a>. <i>DMReview</i>. Archived from <a rel="nofollow" class="external text" href="http://www.dmreview.com/article_sub.cfm?articleId=689">the original</a> on 2005-03-15<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-07-15</span></span>.</cite></li>

<li><cite id="CITEREFMayerMcGoughGulamaliYoung2002" class="citation web cs1">Mayer, Anthony; McGough, Stephen; Gulamali, Murtaza; Young, Laurie; Stanton, Jim; Newhouse, Steven; Darlington, John (2002). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20120204225254/http://www.lesc.ic.ac.uk/iceni/pdf/Grid2002.pdf">"Meaning and Behaviour in Grid Oriented Components"</a> <span class="cs1-format">(PDF)</span>. London e-Science Centre, Imperial College of Science, Technology and Medicine. Archived from <a rel="nofollow" class="external text" href="http://www.lesc.ic.ac.uk/iceni/pdf/Grid2002.pdf">the original</a> <span class="cs1-format">(PDF)</span> on 2012-02-04.</cite></li>

<li><cite id="CITEREFBlackHuangKosterWalpole2002" class="citation journal cs1">Black, Andrew P.; Huang, Jie; Koster, Rainer; Walpole, Jonathan; Pu, Calton (2002). <a rel="nofollow" class="external text" href="http://web.cecs.pdx.edu/~black/publications/Mms062%203rd%20try.pdf">"Infopipes: An abstraction for multimedia streaming"</a> <span class="cs1-format">(PDF)</span>. <i>Multimedia Systems</i>. <b>8</b> (5). Springer-Verlag: <span class="nowrap">406–</span>419. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1007%2Fs005300200062">10.1007/s005300200062</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:5700383">5700383</a><span class="reference-accessdate">. Retrieved <span class="nowrap">2006-08-10</span></span>.</cite></li>

<li><cite id="CITEREFKra2004" class="citation journal cs1">Kra, David (October 2004). <a rel="nofollow" class="external text" href="http://www-128.ibm.com/developerworks/grid/library/gr-ziseries/">"zSeries and iSeries servers in the grid domain"</a>. <i>IBM DeveloperWorks</i><span class="reference-accessdate">. Retrieved <span class="nowrap">2006-07-13</span></span>.</cite></li>

<li><cite id="CITEREFLudäscherAltintasBerkleyHiggins2004" class="citation web cs1">Ludäscher, Bertram; Altintas, Ilkay; Berkley, Chad; et al. (September 2004). <a rel="nofollow" class="external text" href="http://users.sdsc.edu/~ludaesch//Paper/kepler-swf.pdf">"Scientific Workflow Management and the Kepler System"</a> <span class="cs1-format">(PDF)</span>. San Diego Supercomputer Center<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-07-14</span></span>.</cite></li>

<li><cite id="CITEREFBickleRichardsonSmith2005" class="citation web cs1">Bickle, Jerry; Richardson, Kevin; Smith, Jeff (2005). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20060714093003/http://www.omg.org/docs/robotics/05-01-06.pdf">"OMG Software Radio Specification Overview for Robotics"</a> <span class="cs1-format">(PDF)</span>. Object Management Group - Software-Based Communications. Archived from <a rel="nofollow" class="external text" href="http://www.omg.org/docs/robotics/05-01-06.pdf">the original</a> <span class="cs1-format">(PDF)</span> on 2006-07-14<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-07-15</span></span>.</cite></li>

<li><cite id="CITEREFBlažević2006" class="citation journal cs1">Blažević, Mario (2006). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20070918094106/http://www.idealliance.org/papers/extreme/proceedings/html/2006/Blazevic01/EML2006Blazevic01.html">"Streaming Component Combinators"</a>. <i>Proceedings of Extreme Markup Languages</i>. Archived from <a rel="nofollow" class="external text" href="http://www.idealliance.org/papers/extreme/Proceedings/html/2006/Blazevic01/EML2006Blazevic01.html">the original</a> on 2007-09-18<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-11-09</span></span>.</cite></li>

<li><cite id="CITEREFKauler1999" class="citation book cs1">Kauler, Barry (1999). <i>Flow Design for Embedded Systems, 2nd Edition</i>. R&D Books/Miller Freeman. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-87930-555-0</bdi>.</cite></li>

/* start https://en.wikipedia.org/ */

.mw-parser-output .citation{word-wrap:break-word}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}

/* end https://en.wikipedia.org/ */

</style><span class="citation patent" id="CITEREFGuthery,_Scott_B.Barth,_Paul_S.Barstow,_David_R.1993"><a rel="nofollow" class="external text" href="https://worldwide.espacenet.com/textdoc?DB=EPODOC&IDX=US5204965">US patent 5204965</a>, Guthery, Scott B.; Barth, Paul S. & Barstow, David R., "Data processing system using stream stores", issued 1993-04-20, assigned to Schlumberger Technology Corporation</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Apatent&rft.number=5204965&rft.cc=US&rft.title=Data+processing+system+using+stream+stores&rft.inventor=Guthery%2C+Scott+B.&rft.assignee=Schlumberger+Technology+Corporation&rft.date=1993-04-20&rft.prioritydate=YYYY-MM-DD"><span style="display: none;"> </span></span></li>

<li><cite id="CITEREFMorrison2013" class="citation journal cs1">Morrison, J. Paul (March 2013). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20140808230430/http://ersaconf.org/ersa-adn/Paul-Morrison.php">"Flow-Based Programming"</a>. <i>Application Developers' News</i> (1). Archived from <a rel="nofollow" class="external text" href="http://ersaconf.org/ersa-adn/Paul-Morrison.php">the original</a> on 2014-08-08<span class="reference-accessdate">. Retrieved <span class="nowrap">2014-05-25</span></span>.</cite></li>

<li><cite id="CITEREFStaplin2006" class="citation web cs1">Staplin, George Peter (2006). <a rel="nofollow" class="external text" href="http://www.tcl.tk/community/tcl2006/abstracts/wed-pm1-4.html">"Tcl Flow-Based Programming - TFP"</a><span class="reference-accessdate">. Retrieved <span class="nowrap">2010-10-07</span></span>.</cite></li>

<li><cite id="CITEREFJohnstonHannaMillar2004" class="citation journal cs1">Johnston, Wesley M.; Hanna, J. R. Paul; Millar, Richard J. (March 2004). "Advances in dataflow programming languages". <i>ACM Computing Surveys</i>. <b>36</b> (1): <span class="nowrap">1–</span>34. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F1013208.1013209">10.1145/1013208.1013209</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:5257722">5257722</a>.</cite></li>

<li><cite id="CITEREFKosterBlackHuangWalpole2003" class="citation journal cs1">Koster, Rainer; Black, Andrew P.; Huang, Jie; Walpole, Jonathan; Pu, Calton (April 2003). <a rel="nofollow" class="external text" href="http://portal.acm.org/citation.cfm?id=777886&dl=acm&coll=&CFID=15151515&CFTOKEN=6184618">"Thread transparency in information flow middleware"</a>. <i>Software: Practice and Experience</i>. <b>33</b> (4): <span class="nowrap">321–</span>349. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.15.3933">10.1.1.15.3933</a></span>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1002%2Fspe.510">10.1002/spe.510</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:37356020">37356020</a><span class="reference-accessdate">. Retrieved <span class="nowrap">2006-12-05</span></span>.</cite></li>

<li><cite id="CITEREFStevenson1995" class="citation web cs1">Stevenson, Tony (February 1995). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20060925122550/http://www.melbpc.org.au/pcupdate/9502/9502article7.htm">"Review of "Flow-Based Programming""</a>. PC Update, the magazine of Melbourne PC User Group, Australia. Archived from <a rel="nofollow" class="external text" href="http://www.melbpc.org.au/pcupdate/9502/9502article7.htm">the original</a> on 2006-09-25<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-12-06</span></span>.</cite></li>

<li><cite id="CITEREFLea2001" class="citation web cs1">Lea, Doug (May 2001). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20060907053230/http://g.oswego.edu/dl/cpj/s4.2.html">"Composing Oneway Messages"</a>. Archived from <a rel="nofollow" class="external text" href="http://g.oswego.edu/dl/cpj/s4.2.html">the original</a> on 2006-09-07<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-12-06</span></span>.</cite></li>

<li><cite id="CITEREFBowersLudäscherNguCritchlow" class="citation web cs1">Bowers, Shawn; Ludäscher, B.; <a href="Anne_Ngu" title="Anne Ngu">Ngu, A.H.H.</a>; Critchlow, T. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20070205141148/http://daks.ucdavis.edu/~ludaesch/289F-SQ06/handouts/7-templates-frames-sciflow.pdf">"Enabling Scientific Workflow Reuse through Structured Composition of Dataflow and Control-Flow"</a> <span class="cs1-format">(PDF)</span>. SciFlow '06. Archived from <a rel="nofollow" class="external text" href="http://daks.ucdavis.edu/~ludaesch/289F-SQ06/handouts/7-templates-frames-sciflow.pdf">the original</a> <span class="cs1-format">(PDF)</span> on 2007-02-05<span class="reference-accessdate">. Retrieved <span class="nowrap">2006-12-06</span></span>.</cite></li>

<li><cite id="CITEREFSorberKostadinovGarberBrennan2007" class="citation book cs1">Sorber, Jacob; Kostadinov, Alexander; Garber, Matthew; Brennan, Matthew; Corner, Mark D.; Berger, Emery D. (2007). "Eon". <i>Eon: a language and runtime system for perpetual systems</i>. Proceedings of the 5th international conference on Embedded networked sensor systems - Session: Power management. p. 161. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F1322263.1322279">10.1145/1322263.1322279</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9781595937636</bdi>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:12851752">12851752</a>.</cite></li>

<li><cite id="CITEREFFiedlerDasey2014" class="citation web cs1">Fiedler, Lars; Dasey, Timothy (2014). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20140826162959/http://www.ntis.gov/search/product.aspx?ABBR=ADA603097">"Systems and Methods for Composable Analytics"</a>. National Technical Information Service. Archived from <a rel="nofollow" class="external text" href="http://www.ntis.gov/search/product.aspx?ABBR=ADA603097">the original</a> on 2014-08-26<span class="reference-accessdate">. Retrieved <span class="nowrap">2014-04-01</span></span>.</cite></li>

<li><cite id="CITEREFMatt2014" class="citation book cs1">Matt, Carkci (2014). <i>Dataflow and Reactive Programming Systems: A Practical Guide</i>. CreateSpace Independent Publishing Platform. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1497422445</bdi>.</cite></li>

<li><cite id="CITEREFLampaDahlöAlvarssonSpjuth2018" class="citation journal cs1">Lampa, Samuel; Dahlö, Martin; Alvarsson, Jonathan; Spjuth, Ola (2018). <a rel="nofollow" class="external text" href="http://uu.diva-portal.org/smash/get/diva2:1242254/FULLTEXT02">"SciPipe - A workflow library for agile development of complex and dynamic bioinformatics pipelines"</a>. <i>bioRxiv</i>: 380808. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://doi.org/10.1101%2F380808">10.1101/380808</a></span><span class="reference-accessdate">. Retrieved <span class="nowrap">2018-08-02</span></span>.</cite></li></ul>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hlist dl,.mw-parser-output .hlist ol,.mw-parser-output .hlist ul{margin:0;padding:0}.mw-parser-output .hlist dd,.mw-parser-output .hlist dt,.mw-parser-output .hlist li{margin:0;display:inline}.mw-parser-output .hlist.inline,.mw-parser-output .hlist.inline dl,.mw-parser-output .hlist.inline ol,.mw-parser-output .hlist.inline ul,.mw-parser-output .hlist dl dl,.mw-parser-output .hlist dl ol,.mw-parser-output .hlist dl ul,.mw-parser-output .hlist ol dl,.mw-parser-output .hlist ol ol,.mw-parser-output .hlist ol ul,.mw-parser-output .hlist ul dl,.mw-parser-output .hlist ul ol,.mw-parser-output .hlist ul ul{display:inline}.mw-parser-output .hlist .mw-empty-li{display:none}.mw-parser-output .hlist dt::after{content:": "}.mw-parser-output .hlist dd::after,.mw-parser-output .hlist li::after{content:" · ";font-weight:bold}.mw-parser-output .hlist dd:last-child::after,.mw-parser-output .hlist dt:last-child::after,.mw-parser-output .hlist li:last-child::after{content:none}.mw-parser-output .hlist dd dd:first-child::before,.mw-parser-output .hlist dd dt:first-child::before,.mw-parser-output .hlist dd li:first-child::before,.mw-parser-output .hlist dt dd:first-child::before,.mw-parser-output .hlist dt dt:first-child::before,.mw-parser-output .hlist dt li:first-child::before,.mw-parser-output .hlist li dd:first-child::before,.mw-parser-output .hlist li dt:first-child::before,.mw-parser-output .hlist li li:first-child::before{content:" (";font-weight:normal}.mw-parser-output .hlist dd dd:last-child::after,.mw-parser-output .hlist dd dt:last-child::after,.mw-parser-output .hlist dd li:last-child::after,.mw-parser-output .hlist dt dd:last-child::after,.mw-parser-output .hlist dt dt:last-child::after,.mw-parser-output .hlist dt li:last-child::after,.mw-parser-output .hlist li dd:last-child::after,.mw-parser-output .hlist li dt:last-child::after,.mw-parser-output .hlist li li:last-child::after{content:")";font-weight:normal}.mw-parser-output .hlist ol{counter-reset:listitem}.mw-parser-output .hlist ol>li{counter-increment:listitem}.mw-parser-output .hlist ol>li::before{content:" "counter(listitem)"\a0 "}.mw-parser-output .hlist dd ol>li:first-child::before,.mw-parser-output .hlist dt ol>li:first-child::before,.mw-parser-output .hlist li ol>li:first-child::before{content:" ("counter(listitem)"\a0 "}

/* end https://en.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r1236075235">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbox{box-sizing:border-box;border:1px solid #a2a9b1;width:100%;clear:both;font-size:88%;text-align:center;padding:1px;margin:1em auto 0}.mw-parser-output .navbox .navbox{margin-top:0}.mw-parser-output .navbox+.navbox,.mw-parser-output .navbox+.navbox-styles+.navbox{margin-top:-1px}.mw-parser-output .navbox-inner,.mw-parser-output .navbox-subgroup{width:100%}.mw-parser-output .navbox-group,.mw-parser-output .navbox-title,.mw-parser-output .navbox-abovebelow{padding:0.25em 1em;line-height:1.5em;text-align:center}.mw-parser-output .navbox-group{white-space:nowrap;text-align:right}.mw-parser-output .navbox,.mw-parser-output .navbox-subgroup{background-color:#fdfdfd}.mw-parser-output .navbox-list{line-height:1.5em;border-color:#fdfdfd}.mw-parser-output .navbox-list-with-group{text-align:left;border-left-width:2px;border-left-style:solid}.mw-parser-output tr+tr>.navbox-abovebelow,.mw-parser-output tr+tr>.navbox-group,.mw-parser-output tr+tr>.navbox-image,.mw-parser-output tr+tr>.navbox-list{border-top:2px solid #fdfdfd}.mw-parser-output .navbox-title{background-color:#ccf}.mw-parser-output .navbox-abovebelow,.mw-parser-output .navbox-group,.mw-parser-output .navbox-subgroup .navbox-title{background-color:#ddf}.mw-parser-output .navbox-subgroup .navbox-group,.mw-parser-output .navbox-subgroup .navbox-abovebelow{background-color:#e6e6ff}.mw-parser-output .navbox-even{background-color:#f7f7f7}.mw-parser-output .navbox-odd{background-color:transparent}.mw-parser-output .navbox .hlist td dl,.mw-parser-output .navbox .hlist td ol,.mw-parser-output .navbox .hlist td ul,.mw-parser-output .navbox td.hlist dl,.mw-parser-output .navbox td.hlist ol,.mw-parser-output .navbox td.hlist ul{padding:0.125em 0}.mw-parser-output .navbox .navbar{display:block;font-size:100%}.mw-parser-output .navbox-title .navbar{float:left;text-align:left;margin-right:0.5em}body.skin--responsive .mw-parser-output .navbox-image img{max-width:none!important}@media print{body.ns-0 .mw-parser-output .navbox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style></div><div role="navigation" class="navbox" aria-labelledby="Programming_paradigms_(Comparison_by_language)368" style="padding:3px"><table class="nowraplinks mw-collapsible autocollapse navbox-inner" style="border-spacing:0;background:transparent;color:inherit"><tbody><tr><th scope="col" class="navbox-title" colspan="2"><style data-mw-deduplicate="TemplateStyles:r1239400231">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbar{display:inline;font-size:88%;font-weight:normal}.mw-parser-output .navbar-collapse{float:left;text-align:left}.mw-parser-output .navbar-boxtext{word-spacing:0}.mw-parser-output .navbar ul{display:inline-block;white-space:nowrap;line-height:inherit}.mw-parser-output .navbar-brackets::before{margin-right:-0.125em;content:"[ "}.mw-parser-output .navbar-brackets::after{margin-left:-0.125em;content:" ]"}.mw-parser-output .navbar li{word-spacing:-0.125em}.mw-parser-output .navbar a>span,.mw-parser-output .navbar a>abbr{text-decoration:inherit}.mw-parser-output .navbar-mini abbr{font-variant:small-caps;border-bottom:none;text-decoration:none;cursor:inherit}.mw-parser-output .navbar-ct-full{font-size:114%;margin:0 7em}.mw-parser-output .navbar-ct-mini{font-size:114%;margin:0 4em}html.skin-theme-clientpref-night .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}@media(prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}}@media print{.mw-parser-output .navbar{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div id="Programming_paradigms_(Comparison_by_language)368" style="font-size:114%;margin:0 4em"><a href="Programming_paradigm" title="Programming paradigm">Programming paradigms</a> (<a href="Comparison_of_multi-paradigm_programming_languages" title="Comparison of multi-paradigm programming languages">Comparison by language</a>)</div></th></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Imperative_programming" title="Imperative programming">Imperative</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em"></div><table class="nowraplinks navbox-subgroup" style="border-spacing:0"><tbody><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Structured_programming" title="Structured programming">Structured</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Jackson_structured_programming" title="Jackson structured programming">Jackson structures</a></li>

<li><a href="Block_(programming)" title="Block (programming)">Block-structured</a></li>

<li><a href="Modular_programming" title="Modular programming">Modular</a></li>

<li><a href="Non-structured_programming" title="Non-structured programming">Non-structured</a></li>

<li><a href="Procedural_programming" title="Procedural programming">Procedural</a></li>

<li><a href="Programming_in_the_large_and_programming_in_the_small" title="Programming in the large and programming in the small">Programming in the large and in the small</a></li>

<li><a href="Design_by_contract" title="Design by contract">Design by contract</a></li>

<li><a href="Invariant-based_programming" title="Invariant-based programming">Invariant-based</a></li>

<li><a href="Nested_function" title="Nested function">Nested function</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Object-oriented_programming" title="Object-oriented programming">Object-oriented</a><br>(<a href="Comparison_of_programming_languages_(object-oriented_programming)" title="Comparison of programming languages (object-oriented programming)">comparison</a>, <a href="List_of_object-oriented_programming_languages" title="List of object-oriented programming languages">list</a>)</th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Class-based_programming" title="Class-based programming">Class-based</a>, <a href="Prototype-based_programming" title="Prototype-based programming">Prototype-based</a>, <a href="Object-based_language" title="Object-based language">Object-based</a></li>

<li><a href="Agent-oriented_programming" title="Agent-oriented programming">Agent</a></li>

<li><a href="Immutable_object" title="Immutable object">Immutable object</a></li>

<li><a href="Persistent_programming_language" title="Persistent programming language">Persistent</a></li>

<li><a href="Uniform_function_call_syntax" title="Uniform function call syntax">Uniform function call syntax</a></li></ul>

</div></td></tr></tbody></table><div></div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Declarative_programming" title="Declarative programming">Declarative</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em"></div><table class="nowraplinks navbox-subgroup" style="border-spacing:0"><tbody><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Functional_programming" title="Functional programming">Functional</a><br>(<a href="Comparison_of_functional_programming_languages" title="Comparison of functional programming languages">comparison</a>)</th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Recursion_(computer_science)" title="Recursion (computer science)">Recursive</a></li>

<li><a href="Anonymous_function" title="Anonymous function">Anonymous function</a> (<a href="Partial_application" title="Partial application">Partial application</a>)</li>

<li><a href="Higher-order_programming" title="Higher-order programming">Higher-order</a></li>

<li><a href="Purely_functional_programming" title="Purely functional programming">Purely functional</a></li>

<li><a href="Total_functional_programming" title="Total functional programming">Total</a></li>

<li><a href="Strict_programming_language" title="Strict programming language">Strict</a></li>

<li><a href="Generalized_algebraic_data_type" title="Generalized algebraic data type">GADTs</a></li>

<li><a href="Dependent_type" title="Dependent type">Dependent types</a></li>

<li><a href="Functional_logic_programming" title="Functional logic programming">Functional logic</a></li>

<li><a href="Tacit_programming" title="Tacit programming">Point-free style</a></li>

<li><a href="Expression-oriented_programming_language" title="Expression-oriented programming language">Expression-oriented</a></li>

<li><a href="Applicative_programming_language" title="Applicative programming language">Applicative</a>, <a href="Concatenative_programming_language" title="Concatenative programming language">Concatenative</a></li>

<li><a href="Function-level_programming" title="Function-level programming">Function-level</a>, <a href="Value-level_programming" title="Value-level programming">Value-level</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Dataflow_programming" title="Dataflow programming">Dataflow</a></th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul>

<li><a href="Reactive_programming" title="Reactive programming">Reactive</a> (<a href="Functional_reactive_programming" title="Functional reactive programming">Functional reactive</a>)</li>

<li><a href="Signal_programming" class="mw-redirect" title="Signal programming">Signals</a></li>

<li><a href="Stream_processing" title="Stream processing">Streams</a></li>

<li><a href="Synchronous_programming_language" title="Synchronous programming language">Synchronous</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Logic_programming" title="Logic programming">Logic</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Abductive_logic_programming" title="Abductive logic programming">Abductive logic</a></li>

<li><a href="Answer_set_programming" title="Answer set programming">Answer set</a></li>

<li><a href="Constraint_programming" title="Constraint programming">Constraint</a> (<a href="Constraint_logic_programming" title="Constraint logic programming">Constraint logic</a>)</li>

<li><a href="Inductive_logic_programming" title="Inductive logic programming">Inductive logic</a></li>

<li><a href="Nondeterministic_programming" title="Nondeterministic programming">Nondeterministic</a></li>

<li><a href="Ontology_language" title="Ontology language">Ontology</a></li>

<li><a href="Probabilistic_logic_programming" title="Probabilistic logic programming">Probabilistic logic</a></li>

<li><a href="Query_language" title="Query language">Query</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Domain-specific_language" title="Domain-specific language">DSL</a></th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Algebraic_modeling_language" title="Algebraic modeling language">Algebraic modeling</a></li>

<li><a href="Array_programming" title="Array programming">Array</a></li>

<li><a href="Automata-based_programming" title="Automata-based programming">Automata-based</a> (<a href="Action_language" title="Action language">Action</a>)</li>

<li><a href="Command_language" title="Command language">Command</a> (<a href="Spacecraft_command_language" title="Spacecraft command language">Spacecraft</a>)</li>

<li><a href="Differentiable_programming" title="Differentiable programming">Differentiable</a></li>

<li><a href="Grammar-oriented_programming" title="Grammar-oriented programming">Grammar-oriented</a></li>

<li><a href="Interface_description_language" title="Interface description language">Interface description</a></li>

<li><a href="Language-oriented_programming" title="Language-oriented programming">Language-oriented</a></li>

<li><a href="List_comprehension" title="List comprehension">List comprehension</a></li>

<li><a href="Modeling_language" title="Modeling language">Modeling</a></li>

<li><a href="Natural-language_programming" class="mw-redirect" title="Natural-language programming">Natural language</a></li>

<li><a href="Non-English-based_programming_languages" title="Non-English-based programming languages">Non-English-based</a></li>

<li><a href="Page_description_language" title="Page description language">Page description</a></li>

<li><a href="Pipeline_(software)" title="Pipeline (software)">Pipes</a> and <a href="Filter_(software)" title="Filter (software)">filters</a></li>

<li><a href="Probabilistic_programming" title="Probabilistic programming">Probabilistic</a></li>

<li><a href="Quantum_programming" title="Quantum programming">Quantum</a></li>

<li><a href="Scientific_programming_language" title="Scientific programming language">Scientific</a></li>

<li><a href="Scripting_language" title="Scripting language">Scripting</a></li>

<li><a href="Set_theoretic_programming" title="Set theoretic programming">Set-theoretic</a></li>

<li><a href="Simulation_language" title="Simulation language">Simulation</a></li>

<li><a href="Stack-oriented_programming" title="Stack-oriented programming">Stack-based</a></li>

<li><a href="System_programming_language" title="System programming language">System</a></li>

<li><a href="Tactile_programming_language" title="Tactile programming language">Tactile</a></li>

<li><a href="Template_processor" title="Template processor">Templating</a></li>

<li><a href="Transformation_language" title="Transformation language">Transformation</a> (<a href="Graph_rewriting" title="Graph rewriting">Graph rewriting</a>, <a href="Production_system_(computer_science)" title="Production system (computer science)">Production</a>, <a href="Pattern_matching" title="Pattern matching">Pattern</a>)</li>

<li><a href="Visual_programming_language" title="Visual programming language">Visual</a></li></ul>

</div></td></tr></tbody></table><div></div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Concurrent_computing" title="Concurrent computing">Concurrent</a>,<br><a href="Distributed_computing" title="Distributed computing">distributed</a>,<br><a href="Parallel_computing" title="Parallel computing">parallel</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Actor_model" title="Actor model">Actor-based</a></li>

<li><a href="Automatic_mutual_exclusion" title="Automatic mutual exclusion">Automatic mutual exclusion</a></li>

<li><a href="Choreographic_programming" title="Choreographic programming">Choreographic programming</a></li>

<li><a href="Concurrent_logic_programming" title="Concurrent logic programming">Concurrent logic</a> (<a href="Concurrent_constraint_logic_programming" title="Concurrent constraint logic programming">Concurrent constraint logic</a>)</li>

<li><a href="Concurrent_object-oriented_programming" title="Concurrent object-oriented programming">Concurrent OO</a></li>

<li><a href="Macroprogramming" title="Macroprogramming">Macroprogramming</a></li>

<li><a href="Multitier_programming" title="Multitier programming">Multitier programming</a></li>

<li><a href="Organic_computing" title="Organic computing">Organic computing</a></li>

<li><a href="Parallel_programming_model" title="Parallel programming model">Parallel programming models</a></li>

<li><a href="Partitioned_global_address_space" title="Partitioned global address space">Partitioned global address space</a></li>

<li><a href="Process-oriented_programming" title="Process-oriented programming">Process-oriented</a></li>

<li><a href="Relativistic_programming" title="Relativistic programming">Relativistic programming</a></li>

<li><a href="Service-oriented_programming" title="Service-oriented programming">Service-oriented</a></li>

<li><a href="Structured_concurrency" title="Structured concurrency">Structured concurrency</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Metaprogramming" title="Metaprogramming">Metaprogramming</a></th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Attribute-oriented_programming" title="Attribute-oriented programming">Attribute-oriented</a></li>

<li><a href="Automatic_programming" title="Automatic programming">Automatic</a> (<a href="Inductive_programming" title="Inductive programming">Inductive</a>)</li>

<li><a href="Dynamic_programming_language" title="Dynamic programming language">Dynamic</a></li>

<li><a href="Extensible_programming" title="Extensible programming">Extensible</a></li>

<li><a href="Generic_programming" title="Generic programming">Generic</a></li>

<li><a href="Homoiconicity" title="Homoiconicity">Homoiconicity</a></li>

<li><a href="Interactive_programming" title="Interactive programming">Interactive</a></li>

<li><a href="Macro_(computer_science)" title="Macro (computer science)">Macro</a> (<a href="Hygienic_macro" title="Hygienic macro">Hygienic</a>)</li>

<li><a href="Metalinguistic_abstraction" title="Metalinguistic abstraction">Metalinguistic abstraction</a></li>

<li><a href="Multi-stage_programming" title="Multi-stage programming">Multi-stage</a></li>

<li><a href="Program_synthesis" title="Program synthesis">Program synthesis</a> (<a href="Bayesian_program_synthesis" title="Bayesian program synthesis">Bayesian</a>, <a href="Inferential_programming" title="Inferential programming">Inferential</a>, <a href="Programming_by_demonstration" title="Programming by demonstration">by demonstration</a>, <a href="Programming_by_example" title="Programming by example">by example</a>)</li>

<li><a href="Reflective_programming" title="Reflective programming">Reflective</a></li>

<li><a href="Self-modifying_code" title="Self-modifying code">Self-modifying code</a></li>

<li><a href="Symbolic_programming" title="Symbolic programming">Symbolic</a></li>

<li><a href="Template_metaprogramming" title="Template metaprogramming">Template</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Separation_of_concerns" title="Separation of concerns">Separation<br>of concerns</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Aspect-oriented_programming" title="Aspect-oriented programming">Aspects</a></li>

<li><a href="Component-based_software_engineering" title="Component-based software engineering">Components</a></li>

<li><a href="Data-driven_programming" title="Data-driven programming">Data-driven</a></li>

<li><a href="Data-oriented_design" title="Data-oriented design">Data-oriented</a></li>

<li><a href="Event-driven_programming" title="Event-driven programming">Event-driven</a></li>

<li><a href="Feature-oriented_programming" title="Feature-oriented programming">Features</a></li>

<li><a href="Literate_programming" title="Literate programming">Literate</a></li>

<li><a href="Role-oriented_programming" title="Role-oriented programming">Roles</a></li>

<li><a href="Subject-oriented_programming" title="Subject-oriented programming">Subjects</a></li></ul>

</div></td></tr></tbody></table></div>

<div class="navbox-styles"></div><div role="navigation" class="navbox" aria-labelledby="Types_of_programming_languages107" style="padding:3px"><table class="nowraplinks mw-collapsible autocollapse navbox-inner" style="border-spacing:0;background:transparent;color:inherit"><tbody><tr><th scope="col" class="navbox-title" colspan="2"><div id="Types_of_programming_languages107" style="font-size:114%;margin:0 4em"><a href="Programming_paradigm" title="Programming paradigm">Types of programming languages</a></div></th></tr><tr><th scope="row" class="navbox-group" style="width:1%">Level</th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Machine_code" title="Machine code">Machine</a></li>

<li><a href="Assembly_language" title="Assembly language">Assembly</a></li>

<li><a href="Compiled_language" title="Compiled language">Compiled</a></li>

<li><a href="Interpreted_language" class="mw-redirect" title="Interpreted language">Interpreted</a></li></ul>

<ul><li><a href="Low-level_programming_language" title="Low-level programming language">Low-level</a></li>

<li><a href="High-level_programming_language" title="High-level programming language">High-level</a></li>

<li><a href="Very_high-level_programming_language" title="Very high-level programming language">Very high-level</a></li>

<li><a href="Esoteric_programming_language" title="Esoteric programming language">Esoteric</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Programming_language_generations" title="Programming language generations">Generation</a></th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="First-generation_programming_language" title="First-generation programming language">First</a></li>

<li><a href="Second-generation_programming_language" title="Second-generation programming language">Second</a></li>

<li><a href="Third-generation_programming_language" title="Third-generation programming language">Third</a></li>

<li><a href="Fourth-generation_programming_language" title="Fourth-generation programming language">Fourth</a></li>

<li><a href="Fifth-generation_programming_language" title="Fifth-generation programming language">Fifth</a></li></ul>

</div></td></tr></tbody></table></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-04-19" href="https://en.wikipedia.org/wiki/?title=Flow-based_programming&oldid=1286334673">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>